*1126*Highly interactive graphical*401* user interfaces have significantly simplified the use of standard application software packages. And the quality of the user interface has quickly become one of the primary criteria of acceptance for most new software.16
*1128*Developing a good user interface, however, is one of the most problematic*1129* components of producing a software system. Design issues are complex, and implementation and subsequent modification of a user interface can be error-prone and expensive. For many software developers, the cost of providing a high-quality user interface system is a large portion of the overall cost of putting together a new software product. This is especially true for more specialized applications, which must be tailored to the needs of individual users.
The whole issue of user-interface improvement has been motivating researchers since the early 1980’s to find new methods in user-interface technology and to develop new tools that allow end users to produce their own specialized applications. Today, there are two broad categories of systems available for constructing graphical user interfaces: user-interface management systems and interface *501* toolkits.
What Is a User-interface Management System?
*1131**1137*A User-interface Management System (UIMS) is a software system that facilitates construction of a graphical user interface by separating out the user interface from the application components of a computer program. The code that implements the user interface is completely separated from the code for the application itself. This separation enables a UIMS to support independent specification and management of the interface through high-level tools and facilities.17
UIMS does not implement any application code. It abstracts the syntax and semantics of the user interface so that interface designers and even end users can modify the interface quickly without having extensive knowledge of the application being developed. Knowledge of programming is also not usually required, although this is an issue with mixed appeal.
A UIMS generally uses a special purpose language or some formal specification—such as state transition diagrams, constraint grammars, or menu trees—to describe what the interface looks like and the kinds of interactions it supports.18 So interface developers need not be professional programmers; they need only understand the tools of the UIMS they are using.
Because UIMS software is based on abstracting basic elements from contemporary user interfaces, some critics argue that UIMS packages will become obsolete as quickly as user-interface technology itself develops. Others claim that separating a user interface from its application is overly contrived. The user interface and application are linked in many respects, both obvious and subtle. An arbitrary separation of one from the other, some argue, impairs rather than facilitates interface development.19
There is a conflict between the potential benefits of UIMS technology and the concerns of developers over its utility. At the same time, there is a real need for application interface-development systems.
Interface designers, some of whom are nonprogrammers, require a tool that allows them to prototype and evaluate interface designs. And programmers require a tool that allows them to implement user interfaces efficiently. A growing assumption among researchers is that the second alternative — application-interface toolkits — can provide a solution.20*1139*
What Is an Application-interface Toolkit?
*1130*Unlike a UIMS, an application-interface toolkit provides a more general-purpose programming language for building user interfaces. Further, a toolkit is not totally separated from the application. And it usually does implement application code.
Interface toolkits do not all provide the same general range of utilities. Some toolkits are object-oriented*502* systems and some are not. Each toolkit provides its own set of interface-development tools. And some toolkits are specifically aimed at developing interfaces for a specific kind of application.
For example, some interface toolkits that are aimed at document-processing applications actually include objects that comprise the data to be edited. The objects are in the form of text, bitmaps, spreadsheets, or animation editors, which can then be embedded into multimedia documents processed in the application.
Other toolkits are specifically aimed at specifying the layout of interface components—that is, the spatial positioning of components on the screen. These toolkits provide a set of composite classes for interface components. The composite objects maintain pointers to specific functions that control the proper layout of the interface components. Then, if you want to change the layout of the interface components, only the programming function needs to be replaced at runtime.21
More sophisticated toolkits allow both the objects of the interface system as well as constraints between them to be specified.22 By designing in such constraints, dependencies between individual pieces of data can be enforced. This capability is required of any toolkit designed for working with graphical components of an interface. You often need to guarantee that two visually connected objects always stay connected even if one of them is translated.
Among the best known user-interface development kits are the *1136* object-oriented toolkits. As with other object-oriented systems, there is a cloud of myth and mystery surrounding the power they provide. Long-time developers probably remember one of the earliest OOP toolkits—the Smalltalk*990* Model-View-Controller (MVC)*1133*.23 Although the MVC toolkit carries with it some general advantages in being object-oriented, it does not carry the OOP punch that newer toolkits offer developers today.
MVC splits interface components into model, view, and controller elements—each responsible for part of the total function required for handling an interface component. For example, controllers handle only input, and views take care of only output. Because responsibility for handling input and output are not consolidated into a single object, many objects are required in the system. Since objects must communicate in order to handle a component, the costs in communication overhead make MVC less efficient than a simpler, more consolidated toolkit.
Although MVC does not offer the power everyone expects from object-oriented technology, newer OOP toolkits do offer powerful flexibility without compromising efficiency. For example, Macintosh users are increasingly using Apple’s*548* MacApp implementation of the “look and feel” of Macintosh applications.24 While specialized editors are being developed to facilitate access to and modification of MacApp classes, many feel that the resources required by MacApp and its associated MPW environment are too great, in terms of size, complexity and learning time, for most corporate and business development environments.
How Does Prograph Face the Interface?
Prograph’s Application *1127*Builder*52* is an object-oriented, graphical application-interface toolkit*46* that seamlessly integrates the Prograph development environment with the Macintosh ROM-based*951* toolbox and operating system managers to implement the full Mac interface.
 
Prograph provides a hierarchy of system classes for interface development.
Prograph’s object-oriented interface toolkit*924* includes a set of System classes. These classes provide the high-level components necessary for building interface objects. Specific instances of these classes can be specified to provide a wide range of desired interfaces. And special System class editors are used to set basic attributes.
 
Special System class editors*56* are part of the Prograph interface toolkit.
The interface toolkit facilities that Prograph provides are an extension of the environment provided by the editor and interpreter and follow the same design principles. That is, the design of the interface is integrated with its testing in a complete top-down (or look-to-feel) fashion. Once initial menus and windows have been graphically designed and installed, the application can be immediately run.
*1134*User and system events trigger calls to user methods that may not yet exist but that can be created and edited on the fly. By its seamless integration, a Prograph application and the editor run concurrently. The application can be paused and the Application Builder editors used to modify and extend elements of the user interface. New menus, windows, and interface controls within existing windows can be added and the application resumed with new functionality.
With this dynamic run-edit-design-run cycle, *876*Prograph applications*47* take shape and evolve at a much faster rate than those developed in traditional environments requiring complex, sequential edit-link-compile-run cycles. The Prograph code you write is largely related to functional aspects of the application’s computation. The voluminous lines of code necessary to create and manage elements of the user interface are gone in Prograph. You use Application Builder editors to show Prograph what the interface looks like and to specify functional dependencies between interface elements.
Using Application Builder, you are continually showing Prograph what your application looks like and how it behaves, rather than telling it these things by writing code. As has been said, “By showing instead of telling a program what to do, 50-90 percent of an application can be developed without explicit programming, increasing productivity two-ten fold.”25
With these conceptual foundations in mind, you are ready to pursue the Tutorials in Part 2.
t References
1. Nan C. Shu, Visual Programming (Visual Nostrand Reinhold, 1988).
2. W. C. Donelson, “Spatial Management of Information,” Proceedings of ACM SIGGRAPH'78 (August 1978), pp. 203–9; ref: Spatial Data Management Systems (SDMS).
3. K. J. Goldman et al., “ISIS: Interface for a Semantic Information System,” Proceedings of ACM SIGMOD International Conference on the Management of Data (May 1985), pp. 328–42.
4. S. K. Chang et al., “Design Considerations of a Pictorial Database System,” International Journal on Policy Analysis and Information Systems, 1:2 (January 1978), pp. 49–70, ref: The Graphics-Oriented Relational Algebraic Interpreter (GRAIN); and N. Roussopoulos and D. Leifker, “An Introduction to PSQL: A Pictorial Structured Query Language,” Proceedings of the 1984 IEEE Computer Society Workshop on Visual Languages, Hiroshima, Japan (December 1984), pp. 77–87.
5. M. Hirakawa et al., “HI-VISUAL: A Language Supporting Visual Interaction in Programming,” in Visual Languages, S. K. Chang et al., ed. (Plenum Press, 1986), pp. 233–59.
6. R. P. Taylor, Programming Primer (Addison-Wesley, 1982), ref: First Programming Language (FPL); B. E. J. Clark and S. K. Robinson, “A Graphically Interacting Program Monitor,” The Computer Journal, 26:3 (June 1983), pp. 235–8; M. C. Pong and N. Ng, “PIGS—A System for Programming with Interactive Graphical Support,” Software—Practice and Experience, 13:9 (September 1983), pp. 847–55; and M. B. Albizuri-Romero, “GRASE—A Graphical Syntax Directed Editor for Structured Programming,” ACM SIGPLAN Notices, 19:2 (February 1984), pp.28–37.
7. M. M. Zloof, “Query-By-Example,” Proceedings of the National Computer Conference (May 1975), pp. 431–8.
8. S. B. Yao et al., “FORMANAGER: An Office Forms Management System,” ACM Transactions of Office Information Systems, 2:3 (July 1984), pp. 235–62; and N. C. Shu, “FORMAL: A Forms-Oriented and Visual-Directed Application System,” IEEE Computer, 18:8 (August 1985), pp. 38–49.
9. Shu, Visual Programming.
10. L. J. Pinson and R. J. Wiener, An Introduction to Object-Oriented Programming and Smalltalk (Addison-Wesley, 1988).
11. J. B. Dennis, “Data Flow Supercomputers,” in Selected Reprints on Dataflow and Reduction Architectures (Computer Society Press of the IEEE, 1987), pp. 102–10.
12. W. B. Ackerman, “Data Flow Languages,” in Selected Reprints on Dataflow and Reduction Architectures (Computer Society Press of the IEEE, 1987), pp. 179–88.
13. Arvind and D. E. Culler, “Dataflow Architectures,” in Selected Reprints on Dataflow and Reduction Architectures (Computer Society Press of the IEEE, 1987), pp. 79–101.
14. Ackerman, “Data Flow Languages.”
15. A. L. Davis and R. M. Keller, “Data Flow Program Graphs,” in Selected Reprints on Dataflow and Reduction Architectures (Computer Society Press of the IEEE, 1987), pp. 189–204.
16. J. F. Desoi, W. M. Lively, and S. V. Sheppard, “Graphical Specification of User Interfaces with Behavior Abstraction,” in Proceedings of CHI'89, conference held in Austin, Texas, 30 April–4 May, 1989 (New York: ACM, 1989), pp. 139–44.
17. M. A. Linton, J. M. Vlissides, and P. R. Calder, “Composing User Interfaces with InterViews,” IEEE Computer, 22:2 (February 1989), pp. 8–22.
18. See various papers in Proceedings of CHI'89.
19. J. M. Manheimer, R. C. Burnett, and J. A. Wallers, “A Case Study of User Interface Management System Development and Applications,” in Proceedings of CHI'89, pp. 127–32.
20. Manheimer, “A Case Study.”
21. A. J. Palay et al., “The Andrew Toolkit: An Overview,” Proceedings, 1988 Winter USENIX (February 1988), pp. 9–21, as cited in Linton, “Composing User Interfaces.”
22. P. S. Barth, “An Object-Oriented Approach to Graphical Interfaces,” ACM Transactions on Graphics, 5:2 (April 1986), pp. 142–72.
23. G. E. Krasner and S. T. Pope, “A Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80,” Journal of Object-Oriented Programming, 1:3 (August-September, 1988), pp. 26–49.
24. Apple Programmer’s and Developer’s Association, MacApp: The Expandable Macintosh Application (Renton Washington, 1987).
25. T. G. Lewis et al., “Prototypes from Standard User Interface Management Systems,” IEEE Computer, 22:5 (May 1989), pp. 51–60.
